SOURCE SYNCHRONOUS TIMING EXTRACTION, CYCLIZATION AND 

SAMPLING 

Background of the Invention 

5 The increasing reliance upon computer systems to collect, process, 

and analyze data has led to the continuous improvement of the system 
assembly process and associated hardware. With the improvements in 
speed and density of integrated circuits, the cost and complexities of 
designing and testing these integrated circuits has dramatically increased. 

10 Currently, integrated multi-functional Electronic Automation Design (EAD) 

tools are used to design and simulate integrated circuit devices. The design 
of an integrated circuit involves synthesizing device components to meet the 
device specification, including requirements for both device functionality and 
device timing. The design is typically verified against the device 

15 specification via simulation. A simulator, typically integrated into the EAD 

tool, simulates the operation of the design by applying a set of input stimulus 
to the synthesized design, and receiving and monitoring a set of simulated 
output responses. The input stimulus is designed to test the functionality 
and timing requirements of the device specification. The simulator compares 

20 the simulated output response to expected output response values to verify 
operation of the design. Once a design is satisfactorily verified against the 
device specification, a physical implementation of the device (i.e., a 
"prototype") is generated and tested using the simulation test data, including 
respective pairs of input stimulus and expected output response to verify 

25 expected operation of the physical device against the design. 

Simulator tools generally output simulation test data, including 
respective pairs of input stimulus and expected output response, to files 
implementing what is known in the industry as "event-based" data formats. 
Examples of such event-based data formats include the IEEE Standard 

30 1364-2001 Virology Change Dump (VCD) format, or the IEEE Standard 

1450-1999 Standard Test Interface Language (STIL) format. A VCD event- 
based data file, for example, typically contains header information, variable 
definitions (e.g., pin number or name definitions), and the timescale used. 
Next, the file typically contains definitions of the scope and type of variables 
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being dumped, followed by the actual value changes at each simulation time 
increment. Only the variables that change value during a time increment are 
listed. 

In contrast, the integrated circuit testers, typically large complex 

5 industrial Automated Test Equipment (ATE), operate according to fixed 
device cycles. Accordingly, ATE typically requires input test data in files 
implemented according to a "cycle-based" data format. A cycle-based data 
format generally includes a set of vectors and a set of waveforms defined by 
a fixed device cycle time. 

10 The event-based data file format and cycle-based data file format are 

incompatible. Accordingly, in order to utilize the simulation test data 
generated by the simulator to verify operation of the prototype, or to verify 
operation of manufactured devices during production, the event-based 
simulation test data file must be converted to a cycle-based test data file(s) 

15 compatible with the ATE. 

A translator tool typically performs the conversion of event-based 
simulation test data files to cycle-based test data file(s) appropriate for the 
particular ATE testing the prototype or device under test (DUT). One 
incompatibility problem with event-based simulation test data is that event- 

20 based data reflects one time point for each event. In the actual silicon, 

however, the time that an event may occur is actually a range between the 
best case and worst-case extremes. Providing the device timing diagrams, 
which contain the ambiguity regions of the signals' timing, allows the 
translator tool to identify the device cycle that the simulator executes, and 

25 then to test according to the device cycle specification as it appears in the 
timing diagrams to generate a test according to the actual device 
specification. Accordingly, the translator tool essentially imposes a fixed 
cycle on event-based simulation test data in order to extract, from the event- 
based simulation test data, separate waveforms (i.e., timing diagrams 

30 characterized by a fixed set of discrete behaviors) and corresponding 
separate data vectors (i.e., the sequence of those discrete behaviors) 
implemented in the cycle-based file format required by the particular ATE 
that will be testing the physical device. 
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Many integrated circuits designed and manufactured today are high- 
speed digital serial communication devices such as high-speed network 
communication devices including SerDes (Serializer/Deserializer), SONET, 
Gigabit Ethernet, InfiniBand and FibreChannel chips. Serial devices such as 
these rely on a clock signal to transmit and recover data. However, due to 
thermal and other variations, drift, jitter, and other timing irregularities may 
be introduced into the data during data transmission. To compensate for 
this, modern high-speed serial devices are often built to include an internal 
clock recovery system, and the clock signal is embedded within the serial 
data itself. The clock recovery circuitry on the serial receiver includes source 
synchronous functionality, which essentially performs a "snap to grid" on the 
clock signal, adjusting to any detected clock period deviations. "Source 
synchronous" refers to a circuit's ability to resynchronize to a clock that drifts, 
jitters, or exhibits other timing irregularities during data transmission. 

In order to test the functionality of clock recovery circuitry on a serial 
device, test engineers often inject timing irregularities into the test data 
during simulation. This can be done manually by the design engineer, or 
automatically using a timing irregularity injection tool provided with the 
simulator. As just described, however, a conventional translator tool 
essentially imposes a fixed cycle on event-based simulation test data in 
order to extract a separate waveform (i.e., a timing diagram characterized by 
a fixed set of discrete behaviors) and corresponding separate data vector 
(the sequence of those discrete behaviors) from the simulation test data 
format. This is problematic when generating test vectors from a serial device 
simulation containing injected timing irregularities because, since the tester 
requires fixed period device cycles generated based on ideal device 
specification timing diagrams, the translator tool typically cannot match up 
event-based test data containing injected timing irregularities with the ideal 
timing diagrams of the device specification, and thus the cyclization engine is 
often unable to generate device cycles for this type of data. Thus, it is very 
difficult to generate cycle-based test data from event-based test data that 
contains such timing irregularities in order to test the source-synchronous 
hardware on these devices. Accordingly, a need exists for a tool that 
extracts and removes timing irregularities, such as drift and jitter, from event- 
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based simulation test data that contains such injected timing irregularities, to 
generate corresponding "clean" cycle-based test data (i.e., fixed device 
cycles without the injected timing irregularities) in the format specific to the 
particular ATE testing the physical serial device. A need also exists for a 
5 technique for a tool that extracts such timing irregularities and provides the 
extracted timing irregularities to the ATE in a format usable by the ATE to 
allow the ATE to reinject the extracted timing irregularities into the "clean" 
cycle-based test data using the ATE's own timing irregularity injection 
module when testing the device. 

10 
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Summary Of The Invention 
The present invention provides a technique for extracting timing 
irregularities such as drift and jitter from event-based simulated test data with 
intentionally injected timing irregularities to generate cycle-based test data 
without timing irregularities. The invention is preferably integrated into a 
translator tool that converts event-based test data generated by simulators 
and other design tools into cycle-based test data usable by integrated circuit 
testers. The translator tool preferably includes a normalization function that 
normalizes event-based test data containing intentionally injected timing 
irregularities to normalized event-based test data free of the intentionally 
injected timing irregularities. The translator tool also preferably includes 
cyclization engine that cyclizes normalized event-based test data into cycle- 
based test data ready for use by automated test equipment (ATE). 

In one embodiment, the normalization function performs normalization 
of the event-based test data containing intentionally injected timing 
irregularities using a simulated device clock provided by the simulator that 
generated the event-based test data. The normalization function 
compensates the data signal(s) in the event-based test data file by any time 
difference offset between the edges of the simulated device clock and its 
expected edges. The normalization function invokes a jitter extraction 
function and a drift extraction function to remove any existing jitter and/or 
drift from the data signal(s) in the event-based test data. Preferably, any 
extracted jitter and/or drift is recorded in an irregular timing parameters 
memory that may be utilized to generate a timing irregularities file compatible 
with the tester input format for allowing the tester to reinject the timing 
irregularities prior to testing the device under test. 

In another embodiment, the normalization function performs 
normalization of the event-based test data containing intentionally injected 
timing irregularities based on a normalization specification that contains 
allowed variation parameters for the various data signals contained in the 
event-based test data file. The normalization function compensates the data 
signal(s) in the event-based test data file by any time difference offset 
between the edges of the simulated data signal(s) and its expected edges. 
The normalization function invokes a jitter extraction function and a drift 
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extraction function to remove any existing jitter and/or drift from the data 
signal(s) in the event-based test data. Again, any extracted jitter and/or drift 
is recorded in an irregular timing parameters memory that may be utilized to 
generate a timing irregularities file compatible with the tester input format for 
5 allowing the tester to reinject the timing irregularities prior to testing the 
device under test. 
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Brief Description Of The Drawings 
A more complete appreciation of this invention, and many of the 
attendant advantages thereof, will be readily apparent as the same becomes 
better understood by reference to the following detailed description when 
considered in conjunction with the accompanying drawings in which like 
reference symbols indicate the same or similar components, wherein: 

FIG. 1 is a block diagram of an integrated circuit design and test 
system that includes a translator tool implemented in accordance with the 
invention; 

FIG. 2A is an excerpt of an example value change dump (VCD) 
simulation test data file illustrating simulated data that contains no timing 
irregularities; 

FIG. 2B is a timing diagram illustrating the waveform of the variable in 
the VCD file of FIG. 2A; 

FIG. 3A is an excerpt of an example VCD simulation test data file 
illustrating simulated data that contains intentionally injected jitter; 

FIG. 3B is a timing diagram illustrating the waveform of the variable in 
the VCD file of FIG. 3A; 

FIG. 4A is an excerpt of an example VCD simulation test data file 
illustrating simulated data that contains intentionally injected drift; 

FIG. 4B is a timing diagram illustrating the waveform of the variable in 
the VCD file of FIG. 4A; 

FIG. 5A is an excerpt of an example VCD simulation test data file 
illustrating simulated data that contains intentionally injected jitter and drift; 

FIG. 5B is a timing diagram illustrating the waveform of the variable in 
the VCD file of FIG.5A; 

FIG. 6 is a flowchart illustrating an exemplary embodiment of a 
method of operation for performing the functionality of the cyclization engine 
in handling event-based test data comprising intentionally injected timing 
irregularities; 

FIG. 7 is a flowchart illustrating an exemplary embodiment of a 
method for normalizing event-based test data using a simulated device 
clock; 
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FIG. 8A is a flowchart of an exemplary embodiment of a jitter 
extraction method that utilizes the simulated device clock to extract jitter from 
event-based test data with intentionally injected jitter; 

FIG. 8B is a flowchart of an exemplary embodiment of a drift 
extraction method that utilizes the simulated device clock to extract drift from 
event-based test data with intentionally injected drift; 

FIG. 9A is an example VCD file that includes a simulated clock 
recovery signal and a simulated serial data signal that includes intentionally 
injected jitter; 

FIG. 9B is a timing diagram illustrating the simulated clock recovery 
signal and simulated serial data signal of FIG. 9A; 

FIG. 10A is an example VCD file that includes a simulated clock 
recovery signal and a simulated serial data signal that includes intentionally 
injected drift; 

FIG. 1 0B is a timing diagram illustrating the simulated clock recovery 
signal and simulated serial data signal of FIG. 10A; 

FIG. 1 1 A is a flowchart of an exemplary embodiment of a jitter 
extraction method that utilizes a normalization specification to extract jitter 
from event-based test data with intentionally injected jitter; and 

FIG. 11 B is a flowchart of an exemplary embodiment of a drift 
extraction method that utilizes a normalization specification to extract drift 
from event-based test data with intentionally injected drift. 
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Detailed Description 
Turning now to the invention, FIG. 1 is a block diagram of an 
integrated circuit design and test system 10 that includes a translator tool 30 
that implements the technique of the invention. 
5 The input of the translator tool 30 is an event-based simulation test 

data file 21 containing simulated clock period timing irregularities in at least 
one of the data signals. In the illustrative embodiment, the clock period 
timing irregularities are introduced in order to test clock recovery circuitry 52 
present on a device under test (DUT) 50 that is designed to compensate for 

10 such timing irregularities. As known in the art, the "period" of a waveform is 
the time required for one complete cycle of the wave to occur. In a clock 
synchronous system, it is desirable that the period of the clock signal is 
constant and that the clock cycles at precisely the same time during every 
clock period. Timing irregularities, or intrinsic period characteristic flaws, 

15 may take the form of clock jitter, clock drift, or other such clock period 

irregularities. "Clock jitter" is variation in time of the sampling edge of the 
clock signal. "Clock drift" is the linear (first order) component of a systematic 
change in frequency of an oscillator over time. Drift is caused by aging, by 
changes in the environment, and by other factors external to the oscillator. 

20 "Aging" is a change in frequency with time due to internal changes in an 

oscillator. Aging is usually a nearly linear change in the resonance frequency 
that can be either positive or negative, and occurs even when factors 
external to the oscillator, such as environment and power supply, are kept 
constant. Aging has many possible causes, including a buildup of foreign 

25 material on the crystal, changes in the oscillator circuitry, or changes in the 
quartz material or crystal structure. 

An example event-based simulation test data file 21 is formatted 
according to the Value Change Dump (VCD) file format, an IEEE standard 
1364-2001 , which is incorporated herein by reference for all that it teaches. 

30 VCD togs changes to variable values, such as the values of signals, in a file 
during a simulation session. 

FIG. 2A illustrates an excerpt of an example VCD simulation test data 
file for a serial receive data variable ReceiveData generated by the simulator 
that contains no timing irregularities introduced into the data signals. FIG. 
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2B illustrates a timing diagram illustrating the waveforms of the serial receive 
data variable ReceiveData relative to the simulated timescale. As illustrated, 
the edges occur in synchronization with the timescale grid. The data period 
is 100 psec. 

In order to test the clock recovery circuitry, a test engineer might 
utilize the timing irregularity injection tool to introduce timing irregularities in 
the simulation test data. For example, FIG. 3A illustrates an excerpt of an 
example VCD simulation test data file for the serial receive data variable 
ReceiveData of FIG. 2A generated by the simulator that introduces jitter into 
the data signals. FIG. 3B illustrates a timing diagram illustrating the 
waveforms of the serial receive data variable ReceiveData relative to the 
simulated timescale that is represented by the VCD file of FIG. 3A. As 
illustrated, the edges vary relative to the ideal clock period. 

As another example, FIG. 4A illustrates an excerpt of an example 
VCD simulation test data file for the serial receive data variable ReceiveData 
of FIG. 2A generated by the simulator that introduces drift into the data 
signals. FIG. 4B illustrates a timing diagram illustrating the waveform of the 
serial receive data variable ReceiveData relative to the simulated timescale 
that is represented by the VCD file of FIG. 4A. As illustrated, the clock 
period increases linearly over time. 

FIG. 5A illustrates an excerpt of an example VCD simulation test data 
file for the serial receive data variable ReceiveData of FIG. 2A generated by 
the simulator that introduces both jitter and drift into the data signals. FIG. 
5B illustrates a timing diagram illustrating the waveform of the serial receive 
data variable ReceiveData relative to the simulated timescale that is 
represented by the VCD file of FIG. 5A. As illustrated, the clock period 
increases linearly over time and the transition edges vary relative the drifting 
clock period. 

As illustrated in the example VCD format file excerpts illustrated in 
FIGS. 3A, 4A, and 5A, an event-based file format supports the ability to 
include intrinsic clock period irregularities such as jitter and drift in simulated 
test data because the event-based data file logs only changes in the variable 
state and the time the change occurred. 
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The translator tool 30 preferably includes a cyclization engine 32. 
The cyclization engine 32 processes the event-based test data file 21 (e.g., a 
VCD formatted file) to extract a series of synchronized device cycles based 
on timing diagrams 23 describing the device specification. The timing 
5 diagrams 23 may be generated manually by a test engineer, or may be 

extracted from event-based data 21 using a timing extractor which reads the 
VCD simulation test data file 21 and generates a set of waveforms usable by 
the cyclization engine 32 for generating device cycles. 

The cyclization engine 32 operates to match event-based test data 12 

10 to waveforms described in the timing diagrams 23 to generate a series of 
fixed-period device cycles. In a cycle-based file format, if the event-based 
test data 21 includes timing irregularities such as jitter and drift, the 
cyclization engine 32 will be unable to match the irregularly timed data to the 
device timing diagrams 23 and cyclization cannot occur. 

15 In accordance with the invention, the translator tool 30 is therefore 

provided with a normalization function 38 that operates to remove timing 
irregularities from event-based simulation test data 21 containing 
intentionally injected timing irregularities to generate normalized event-based 
test data 31 . This allows the cyclization engine 32 to cyclize the normalized 

20 event-based test data 31 against the device specification timing diagrams 23 
to generate a set of "clean" data vectors 33a and waveforms 33b. 
Preferably, during normalization, the timing irregularities are recorded in an 
irregular timing parameters memory 36 and formatted into a separate file 37 
that is accessible by the tester 40 for reinjecting the simulated timing 

25 irregularities 37 into the clean data vectors 33a and waveforms 33b to test 
the clock recovery circuitry 52 of the serial device 50. 

FIG. 6 is a flowchart illustrating a method of operation 100 of the 
cyclization engine 32 in handling event-based test data comprising 
intentionally injected timing irregularities. As illustrated, the method 100 

30 obtains the fixed device cycle period (step 101). The cyclization engine 32 
uses the device cycle period to impose a fixed timing grid on the device 
cycle vectors and waveforms for each timing interval. The cyclization engine 
32 then extracts a first timing interval of event-based data (step 102). 
Typically, the cyclization engine 32 chooses a span of time in the event- 
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based simulation test data 21 that is equal to the fixed device cycle period. 
For example, if the cyclization engine 32 were cyclizing the event-based test 
file of FIG. 2A, the cyclization engine might be instructed that the device 
cycle period is 100 psec. In this example, the cyclization engine 32 may 
then extract the first 100 psec of events from the event-based test data file of 
FIG. 2A. In the first 100 psec of events, variable ReceiveData transitions 
from logical 1 to logical 0 at 70 psec. 

The cyclization engine 32 then determines whether it should perform 
normalization on the extracted timing interval of event-based data (step 103). 
Continuing with the present example in which the event-based test data 21 
does not contain any intentionally injected timing irregularities, normalization 
need not be performed. Therefore, the cyclization engine 32 attempts to 
match the extracted interval of event-based data against available timing 
diagrams (step 104). If a match is found (as determined in step 105), a 
device cycle corresponding to the extracted interval is generated (step 106). 
In this regard, a data vector is appended to a cycle-based test data vector 
file 33a and a corresponding waveform is appended to a cycle-based test 
data waveform file 33b. If, on the other hand, a match is not found (as 
determined in step 105), a hole in the cyclized data is recorded (step 107). 
At this point, cyclization may end, or it may continue to try to cyclize the 
remaining event-based data intervals. If a match is found, or if a match is 
not found but cyclization is to continue, the cyclization engine 32 determines 
whether the event-based test data 21 includes additional timing intervals to 
be cyclized. If more event-based test data timing intervals remain to be 
cyclized, the cyclization engine repeats the process (steps 102 through 108) 
until all event-based test data has been cyclized, or until a hole has been 
discovered in the data which causes cyclization to end. 

Suppose that instead of processing an event-based test data file in 
which no timing irregularities have been injected, the cyclization engine 32 
instead processes an event-based test data file that does contain 
intentionally injected timing irregularities. In this case, the cyclization engine 
32 may be instructed (e.g., in step 103) to perform normalization on the 
event-based test data 21 in order to allow the cyclization engine 32 to 
properly cyclize the data. In this regard, the cyclization engine 32 generates 
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a sequence of fixed period device cycles (i.e., test vector file 33a and test 
waveform file 33b) and a separate timing irregularities file 37 that instructs 
the tester 40 how to reinject the timing irregularities 35a, 35b extracted from 
the test data 21 . Returning to the method of FIG. 6, after extracting the first 
5 timing interval (step 102), the method 100 determines that normalization is to 
be performed (step 103). There are two preferred embodiments for 
performing normalization. 

The first embodiment utilizes a clock signal 26 generated by the 
simulator 20 during simulation of the simulated device. Typically, the 

10 simulated clock signal is an internal signal generated by the device's clock 
recovery circuitry that is used by the clock recovery circuitry but is not 
generally made available outside the chip. During simulation, however, the 
simulator can easily include this data recovery clock signal available with the 
test data, and therefore in the first embodiment, the simulator 20 does 

15 provide the clock signal 26 as part of the simulated test data 21 . The 
cyclization engine 32 synchronizes the device cycle period with the 
simulated device clock, essentially performing a "snap-to-grid" operation of 
the simulated device clock to the device cycle period grid. The cyclization 
engine 32 attempts to match the extracted interval of event-based data 

20 against available timing diagrams, compensating the timing of the data in the 
event-based data interval according to any time difference between the 
simulated device clock and the device cycle period (step 109). If any timing 
irregularities are discovered in the event-based data interval, the cyclization 
engine preferably records the timing irregularities 35a, 35b for use in 

25 generating a timing irregularities file 37 that instructs the tester how to 

reinject the timing irregularities extracted from the test data (step 110). If no 
match is found, a hole in the cyclized data is recorded. If a match is found 
(as determined in step 105), a device cycle corresponding to the extracted 
interval is generated (step 106). In this regard, a data vector is appended to 

30 a cycle-based test data vector file 33a and a corresponding waveform is 
appended to the cycle-based test data waveform file 33b. At this point, 
cyclization may end, or it may continue to try to cyclize the remaining event- 
based data intervals. If a match is found, or if a match is not found but 
cyclization is to continue, the cyclization engine determines whether the 
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event-based test data includes additional timing intervals to be cyclized (step 
108). If more event-based test data timing intervals remain to be cyclized, 
the cyclization engine 32 repeats the process (steps 102, 103, 109, 110, 
105, 106 or 107, and 108) until all event-based test data 21 has been 
5 cyclized, or until a hole has been discovered in the data which causes 
cyclization to end. 

The second embodiment utilizes a normalization specification 24 that 
is provided to the cyclization engine 32 along with the test data file 21 . The 
normalization specification 24 specifies information such as the percentage 

10 variation that a given data signal is allowed to deviate from the ideal. The 

cyclization engine 32 attempts to match the extracted interval of event-based 
data 21 against available timing diagrams 23, allowing for the specified 
variation in the edge transitions of each data signal as defined in the 
normalization specification 24 (step 111). If any timing irregularities (i.e., 

15 deviations from the ideal matched waveform) are discovered in the event- 
based data interval, the cyclization engine 32 preferably records these timing 
irregularities 35a, 35b in memory 36 (step 112) for use in generating a timing 
irregularities file 37 usable by the tester 50 for reinjecting the timing 
irregularities extracted from the test data into the clean device cycles when 

20 testing the device under test 50. If a match is found, taking into account the 
allowed amount of deviation from the ideal (as determined in step 105), a 
device cycle corresponding to the extracted interval is generated in 
accordance with the ideal matched waveform (step 106). In this regard, a 
device cycle data vector is appended to the cycle-based test data vector file 

25 33a and a corresponding device cycle waveform is appended to the cycle- 
based test data waveform file 33b. If no match is found, a hole in the 
cyclized data is recorded. At this point, cyclization may end, or it may 
continue to try to cyclize the remaining event-based data intervals. If a 
match is found, or if a match is not found but cyclization is to continue, the 

30 cyclization engine determines whether the event-based test data includes 
additional timing intervals to be cyclized. If additional event-based test data 
timing intervals remain to be cyclized, the cyclization engine repeats the 
process (steps 102, 103, 1 1 1 , 1 12, 105, 106 or 107, and 108) until all event- 
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based test data has been cyclized, or until a hole has been discovered in the 
data which causes cyclization to end. 

Turning now in detail to the first embodiment of the normalization 
function 38 of the translator tool 30 of FIG. 1 , FIG. 7 is a flowchart illustrating 
5 a method of operation 200 for normalizing event-based test data using the 
simulated device clock. The method 200 obtains the expected offset 
between the beginning of device cycle period and the ideal device clock 
edge (step 201 ). The method 200 then invokes the jitter extraction function 
34a (step 202), which extracts and removes any jitter from the event-based 

10 test data interval according to a method discussed hereinafter. The method 
200 then invokes the drift extraction function 34b (step 203), which extracts 
and removes any drift from the event-based test data interval according to a 
method discussed hereinafter. The method 200 then returns the normalized 
event-based test data interval, which is devoid of any jitter and/or drift. 

15 Fig. 8A is a flowchart of a method of operation 210 of an exemplary 

embodiment of the jitter extraction function 34a for the first embodiment of 
the normalization function 38. When invoked, the method 210 obtains the 
expected offset between beginning of device cycle period and clock edge 
(step 21 1 ). Typically, the expected offset will be provided by the device 

20 specification or from a test engineer. The method 210 then measures the 
offset between beginning of device cycle period and the simulated clock 
edge (step 212). For example, FIG. 9A illustrates an example VCD file that 
is implemented according to the first embodiment of the invention in which 
the clock recovery signal ReceiveClk that is used in recovering the receive 

25 data ReceiveData is included in the change dump data. The received data 
signal ReceiveData includes intentionally injected jitter and is the same as 
that shown in FIG. 3A. In this example, the expected offset between the 
beginning of the device cycle period and the clock edge is 50 psec for the 
rising edge and 0 psec for the falling edge. FIG. 9B is a timing diagram 

30 illustrating the receive circuitry clock signal ReceiveClock, the simulated 

receive data signal ReceiveData, and the timing diagram of the normalized 
ReceiveData generated by the normalization function 38 which the 
cyclization engine 32 would attempt to match against available timing 
diagrams. As shown in the VCD file of FIG. 9A and the timing diagram of 
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FIG. 9B, the offset from beginning of device cycle period and the simulated 
rising clock edge (step 212 of method 200 of FIG. 8A) in the first 100 psec 
time interval is +55 psec. 

The method 210 then calculates the difference between expected 
5 offset and simulated offset (step 213). Continuing with the present example, 
the difference between expected offset (+50 psec) and simulated offset (+55 
psec) is -5 psec. The method 210 then adds the calculated difference to 
simulated data edge in normalized test data interval (step 214). In the 
present example, as shown in FIGS. 9A and 9B, the simulated ReceiveData 

10 data signal edge is at +75 psec. Accordingly, the simulated ReceiveData 

data signal edge is normalized by -5 psec, resulting in a normalized edge at 
+70 psec. The method 210 then records the calculated difference as a jitter 
parameter indicating the amount of jitter to inject into the normalized cycle- 
based test data interval (step 215). 

15 Fig. 8B is a flowchart of a method of operation 220 of an exemplary 

embodiment of the drift extraction function 34b for the first embodiment of 
the normalization function 38. When invoked, the method 220 obtains the 
expected offset between beginning of device cycle period and clock edge 
(step 221). Typically, the expected offset will be provided by the device 

20 specification or from a test engineer. The method 220 then measures the 
offset between beginning of device cycle period and the simulated clock 
edge (step 222). For example, FIG. 10A illustrates an example VCD file that 
is implemented according to the first embodiment of the invention in which 
the clock recovery signal ReceiveClk that is used in recovering the receive 

25 data ReceiveData is included in the change dump data. The received data 
signal ReceiveData includes intentionally injected drift and is the same as 
that shown in FIG. 4A. In this example, the expected offset between the 
beginning of the device cycle period and the clock edge is 50 psec for the 
rising edge and 0 psec for the falling edge. FIG. 1 0B is a timing diagram 

30 illustrating the receive circuitry clock signal ReceiveClock, the simulated 

receive data signal ReceiveData, and the timing diagram of the normalized 
ReceiveData generated by the normalization function 38 which the 
cyclization engine 32 would attempt to match against available timing 
diagrams. As shown in the VCD file of FIG. 10A and the timing diagram of 
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FIG. 10B, the offset from the beginning of the device cycle period and the 
simulated rising clock edge (step 222 of method 220 of FIG. 8B) in the first 
100 psec time interval is +55 psec. 

The method 220 then calculates the difference between expected 

5 offset and simulated offset (step 223). Continuing with the example shown 
in FIGS. 10A and 10B, the difference between expected offset (+50 psec) 
and simulated offset (+55 psec) is -5 psec. The method 220 then 
determines whether the clock period of the current interval is expanding 
(step 224). This entails that the drift extraction function 34b stores 

10 information about previous intervals or, as in the preferred embodiment, the 
normalization function stores information about previous intervals and 
passes the information to the drift extraction function 34b as a parameter or 
as a pointer to a parameter that stores the information in memory (e.g., 
irregular timing parameter memory 36). Of course, on the first invocation of 

15 the drift extraction function 34b, previous information will be null. In order to 
determine whether the clock period of the current interval is expanding, the 
drift extraction function 34b preferably determines whether the calculated 
difference between expected offset and simulated offset has increased since 
the last interval. If it has, then the method 220 determines whether the clock 

20 period of the previous interval was expanding (step 225). If the clock period 
of both the current interval and the previous interval indicates clock period 
expansion, the method 220 adds the calculated difference to simulated data 
edge in normalized test data interval (step 228). 

If the clock period of the previous interval did not indicate clock period 

25 expansion, then the drift extraction function 34b considers that the data does 
not indicate drift. However, the information of the present interval is 
preferably recorded to allow for the possibility of future drift. 

If the clock period of the present interval did not indicate clock period 
expansion, the method 220 determines whether the clock period is 

30 contracting (step 226). Again, this entails storage of information about 

previous intervals, as previously discussed. In order to determine whether 
the clock period of the current interval is contracting, the drift extraction 
function 34b preferably determines whether the calculated difference 
between expected offset and simulated offset has decreased since the last 
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interval. If it has, then the method 220 determines whether the clock period 
of the previous interval was contracting (step 227). If the clock period of 
both the current interval and the previous interval indicates clock period 
contraction, the method 220 adds the calculated difference to simulated data 
edge in normalized test data interval (step 228). 

If the clock period of the previous interval did not indicate clock 
period contraction, then the method 220 considers that the data does not 
indicate drift. However, the information of the present interval is preferably 
recorded to allow for the possibility of future drift. 

In the present example, as shown in FIGS. 10A and 10B, the 
simulated ReceiveData data signal edge drifts by +5 psec every 100 psec 
interval. Accordingly, the simulated ReceiveData data signal edge is 
normalized by -5 psec every 100 psec interval using the routing of FIG. 8B. 

Turning now in detail to the second embodiment of the normalization 
function 38 of the translator tool 30 of FIG. 1 , FIG. 1 1 A is a flowchart 
illustrating a method of operation 230 for extracting jitter from event-based 
test data using a normalization specification 24. The normalization 
specification contains information defining allowed ranges within which data 
signals contained in the simulated test data file 21 must transition to meet 
device specifications. Typically, for a given data signal, the normalization 
specification will include a minimum transition time and a maximum transition 
time. The normalization specification may tie minimum transition times and 
maximum transition times for certain data signals to the transition times of 
other simulated data signals. 

The method 230 obtains the expected offset between the beginning of 
device cycle period and the ideal data signal edge (step 231). Typically, the 
expected offset will be provided by the device specification or from a test 
engineer. The method 230 then measures the offset between beginning of 
device cycle period and the simulated data signal edge (step 232). Referring 
to the example of FIG. 9A and 9B, the expected offset between the 
beginning of the device cycle period and the data signal edge is 20 psec for 
the rising edge and 70 psec for the falling edge. As shown in the VCD file of 
FIG. 9A and the timing diagram of FIG. 9B, the offset from beginning of 
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device cycle period and the simulated falling clock edge (step 232 of method 
230 of FIG. 1 1 A) in the first 100 psec time interval is +75 psec. 

The method 230 then calculates the difference between expected 
offset and simulated offset (step 233). Continuing with the present example, 

5 the difference between expected offset (+70 psec) and simulated offset (+75 
psec) is -5 psec. The method then determines whether the difference 
between expected offset (+70 psec) and simulated offset (+75 psec) is within 
the time range allowed by normalization specification for this data signal. If 
not, then there cannot be a match between the event-based test data 

10 interval and the current waveform that is being tested against. If the edge 
does occur within the allowed time range, the method 230 adds the 
calculated difference to simulated data edge in normalized test data interval 
(step 235). In the present example, as shown in FIGS. 9A and 9B, the 
simulated ReceiveData data signal edge is at +75 psec. Accordingly, the 

15 simulated ReceiveData data signal edge is normalized by -5 psec, resulting 
in a normalized edge at +70 psec. The method 230 then records the 
calculated difference as a jitter parameter indicating the amount of jitter to 
inject into the normalized cycle-based test data interval (step 236). 

Fig. 1 1 B is a flowchart of a method of operation 240 of an exemplary 

20 embodiment of the drift extraction function 34b for the second embodiment 
of the normalization function 38 in which a normalization specification 24 is 
utilized to normalize the event-based test data. When invoked, the method 
240 obtains the expected offset between the beginning of device cycle 
period and the ideal data signal edge (step 241). Typically, the expected 

25 offset will be provided by the device specification or from a test engineer. 
The method 240 then measures the offset between beginning of device 
cycle period and the simulated data signal edge (step 242). Referring to the 
example of FIG. 10A and 10B, the expected offset between the beginning of 
the device cycle period and the data signal edge is 20 psec for the rising 

30 edge and 70 psec for the falling edge. As shown in the VCD file of FIG. 10A 
and the timing diagram of FIG. 10B, the offset from beginning of device cycle 
period and the simulated falling data signal edge in the first 100 psec time 
interval is +75 psec. 
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The method 240 then calculates the difference between expected 
offset and simulated offset (step 243). Continuing with the example shown 
in FIGS. 10A and 10B, the difference between expected offset (+70 psec) 
and simulated offset (+75 psec) is -5 psec. The method 240 then 
5 determines whether the clock period of the current interval is expanding 
(step 244). This entails that the drift extraction function 34b stores 
information about previous intervals or, as in the preferred embodiment, the 
normalization function stores information about previous intervals and 
passes the information to the drift extraction function 34b as a parameter or 

10 as a pointer to a parameter that stores the information in memory (e.g., 

irregular timing parameter memory 36). Of course, on the first invocation of 
the drift extraction function 34b, previous information will be null. In order to 
determine whether the clock period of the current interval is expanding, the 
drift extraction function 34b preferably determines whether the calculated 

15 difference between expected offset and simulated offset has increased since 
the last interval. If it has, then the method 240 determines whether the clock 
period of the previous interval was expanding (step 245). If the clock period 
of both the current interval and the previous interval indicates clock period 
expansion, the method 240 adds the calculated difference to simulated data 

20 edge in normalized test data interval (step 248). 

If the clock period of the previous interval did not indicate clock period 
expansion, then the method 240 considers that the data does not indicate 
drift. However, the information of the present interval is preferably recorded 
to allow for the possibility of future drift. 

25 If the clock period of the present interval did not indicate clock period 

expansion, the method 240 determines whether the clock period is 
contracting (step 246). Again, this entails storage of information about 
previous intervals, as previously discussed. In order to determine whether 
the clock period of the current interval is contracting, the method 240 

30 preferably determines whether the calculated difference between expected 
offset and simulated offset has decreased since the last interval. If it has, 
then the method 240 determines whether the clock period of the previous 
interval was contracting (step 247). If the clock period of both the current 
interval and the previous interval indicates clock period contraction, the 
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method 240 adds the calculated difference to simulated data edge in 
normalized test data interval (step 248). 

If the clock period of the previous interval did not indicate clock 
period contraction, then the method 240 considers that the data does not 

5 indicate drift. However, the information of the present interval is preferably 
recorded to allow for the possibility of future drift. 

In the present example, as shown in FIGS. 10A and 10B, the 
simulated ReceiveData data signal edge drifts by +5 psec every 100 psec 
interval. Accordingly, the simulated ReceiveData data signal edge is 

10 normalized by -5 psec every 100 psec interval using the routing of FIG. 1 1B. 

Returning now to FIG. 1 , as just described, the normalization function 
38 normalizes event-based test data containing intentionally injected timing 
irregularities to generate normalized (or "clean") event-based test data 31 
with the injected timing irregularities removed. The cyclization engine 32 

15 then operates to cyclize the normalized event-based test data 31 to generate 
a "clean" set of cycle-based test vectors 33a and a "clean" set of cycle-based 
waveforms 33b that are compatible with the required file format of the tester 
40. The tester 40 may use the test vectors 33a and test waveforms 33b to 
test the device under test 50 without any of the simulated timing 

20 irregularities. However, in order to test the clock recovery circuitry, the 

simulated timing irregularities need to be reinjected back into the test vectors 
33a and corresponding test waveforms 33b. 

As previously described, the jitter extraction function 34a and drift 
extraction function 34b preferably record the extracted timing irregularities in 

25 a timing irregularities file 37. In the preferred embodiment, the tester 

comprises a timing irregularities tool 42 that reads the timing irregularities file 
37 and reinjects the timing irregularities defined in the timing irregularities file 
37 into the corresponding device cycles of the test data (comprising test 
vectors 33a and corresponding test waveforms 33b) prior to applying the test 

30 data to the device under test 50 for testing. As known in the art, the test 

data 33a, 33b also includes the expected responses. This allows the tester 
to determine whether or not the clock recovery circuitry 52 of the physical 
device under test 50 is operating according to specification. 
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In addition, the tester 40 preferably includes source synchronous 
circuitry 44. The source synchronous circuitry 44 includes a reference clock 
input that is connectable directly to the DUT clock recovery circuitry clock 53 
to allow the tester to monitor how well the clock recovery circuitry 52 of the 
device under test 50 is adapting to the intentionally injected timing 
irregularities. This is important in determining whether the clock recovery 
circuitry 52 is adapting to timing irregularities at a level within the device 
specification. The tester can then compare how well the clock recovery 
circuitry 52 of the DUT 50 is operating to recover simulated data to the level 
of recovery expected via the simulation results. 

Although this preferred embodiment of the present invention has been 
disclosed for illustrative purposes, those skilled in the art will appreciate that 
various modifications, additions and substitutions are possible, without 
departing from the scope and spirit of the invention as disclosed in the 
accompanying claims. For example, it should be understood that the 
translator tool 30 includes processing means such as a microprocessor, an 
FPGA, a computer, or other such computerized hardware , and memory that 
stores program instructions that implement the functionality of any one or 
more of the normalization function, the cyclization engine, the jitter extraction 
function, and the drift extraction function. It will be further understood that 
any of the program instructions that implement the functionality of any one or 
more of the normalization function, the cyclization engine, the jitter extraction 
function, and the drift extraction function can be stored on a computer 
readable storage medium herein known or hereinafter developed tangibly 
embodying these program instructions. It is also possible that other benefits 
or uses of the currently disclosed invention will become apparent over time. 
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